perm filename NOTES[EAL,HE]1 blob
sn#679402 filedate 1982-09-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00006 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 Things to do:
C00009 00003 Bugs
C00013 00004 Things to watch out for:
C00014 00005 General notes
C00019 00006 Files on the UDP (ROBOT3):
C00027 ENDMK
C⊗;
Things to do:
It looks like, with full memory-resident overlaying, we have about
14000 bytes of memory left. Use it sparingly!
Sometime soon, combine some of the overlays, like arithn, paux1&2, etc.
When receiving a ↑C - should signal arm code with (some event flag - later)
a message. Better put this in the main loop in IMAIN - is there room?
Put more debug stuff in (↑Y).
During initArms - should make cursor point to where next char typed will
be. Is there an easy way to do this? Also make it look a little better.
Maybe set ppSize to 6 or so. Also, put in ppOutNow's after the prompt
char is typed.
When eProcParse is called, make sure it doesn't overflow the stack
with its local array.
---------- How to improve it ----------------------------------------
Try and find some way to increase the size of the heap. Maybe have
another task running that just stores stuff??
Maybe have one module in a resident overlay that just stores Listing array.
---------- Other stuff ----------------------------------------
Does it increase the size of a module to include external references that
are not actually used? Test this out. There's a difference between
unused routines that need to call an overlay and those for which an overlay
call already exists.
Possibly remove alloc.pas & replace with standard new & dispose.
Make a little test program to see if dispose actually works.
Call Chris Moe about latest version of Pascal-1. The latest version OSMI
supplies is 1.2K; we have 1.2F. They confirmed that 2.0 cannot deal with AL.
(we're site # 1-665).
Bugs
⊗ If you type in this program
begin
scalar i;
for i:=1 til 3 do begin
move garm to garm-4*zhat;
move garm to garm+4*zhat;
end;
end;
and run it, then stop it with control-C while it's doing a move,
it'll say "No processes currently active" and stop, pointing the cursor
to line 1; saying "@" does nothing. Saying !P makes it go into a loop
(which you can stop with ↑C).
⊗ Fix the ↑S problem. Use STEST.AL to test it.
May have to do this by trial/error since stest.pas doesn't seem to do it!
You might put in stuff to look for the ↑S and stop output until ↑Q is rec'd;
where to do this? -- in disp.mac, in the calling routines? Have a character
ast that checks? Maybe make it wait for a bit (one tick?) after it does
inserts and deletes. Shouldn't be too hard.. may need to make the amt of
time depend on how many lines - e.g. 16 ms = 1 tick per line?
⊗ Running this program
begin
move garm to garm-7*zhat
with duration=7
on |force(zhat)| >= 20*oz do
begin
stop garm
print("Got it",crlf);
end;
end;
and pushing on the arm as it goes down (to signal the force monitor)
not only does not trigger the force monitor, but when the motion completes,
it dies (ref thru nil ptr) @ PC=162164.
⊗ Sometimes I see "old line wasn't freed"; could this be the potential bug
in PP:
Look at pp.2/5p/25l - should we call relLine in here somewhere?
that I saw before?
⊗ The following is a bug:
Suppose you're entering a program into the editor:
begin
end;
↓
begin
scalar procedure sum(value scalar n);
begin
end;
end;
If you now try to insert the declaration "scalar i,j;" in front of
the procedure declaration, it says "can't have a declaration here".
If, on the other hand, you first put in the scalar decl and then,
following that, put the proc decl, it doesn't complain.
⊗ This little program doesn't get read in right - barfs at the "trans t1,..."
line. Inserting the same line into the program works, though.
begin
trans f;
frame f1,f2;
frame f3,f4;
trans t1,t2,t3; {dies here}
scalar i,j,k;
print("Hi there",crlf);
end;
Things to watch out for:
⊗ Watch out when EDIT calls FlushSomething - need to call Edit back in.
⊗ When EDIT calls FlushVar (defined edit/17p)
it creates a lot of problems! Check carefully.
General notes
To fix work file problem during TKB:
REA TKB 10 DK1:
The total size of the AL system is 342764 (decimal bytes)
This is as of about July 15
Event size is 6 bytes.
Enventry size is 6 bytes.
Ident size is 8 bytes.
Token size is 8 bytes.
Resword size is 8 bytes.
String size is 12 bytes.
Node size is 12 bytes.
Cmoncb size is 12 bytes.
Vector size is 14 bytes.
Varidef size is 14 bytes.
Frame size is 16 bytes.
Envheader size is 16 bytes.
Stmnt size is 22 bytes.
Environment size: 22 bytes.
Pdb size is 28 bytes.
Trans size is 50 bytes.
Cursorp size is 8 bytes.
Files on the UDP (ROBOT3):
[AL0,RV] Contains a snapshot of AL source files May 28, 1982, before
I changed anything (from Ron's [pas,arg]).
[AL1,RV] A snapshot of the .PAS files in which I changed ↑x to xp.
[AL2,RV] Contains a snapshot of the .PAS files taken on June 9, 1982.
These are to be SRCCOM'd to later versions of the .PAS files
on [al,he] which Ron may change to correct bugs.
The version running on the 11 is made from exactly the source
code found in [al2,rv]. Compare these files on [al2,rv] to
the ones in [al,he], make the appropriate changes to the
.2 files, and (important) copy the new versions of the .pas
files on [al,he] to [al2,rv].
[AL3,RV] All the .11 files from June 29, 1982. This is the initial
editor-less version which ran on the 11 without the arm code
interface.
[AL4,RV] Contains the working version, without arm code communication,
of AL with Editor. Also some misc stuff.
[AL5,RV] This is the initial version of AL with arm code communication.
No editor..
[AL6,RV] This is the first working version of EAL with arm code
communication. There may be compile errors in the code.
In fact there are!
[AL7,RV] The last working version of EAL, version 1 Pascal.
This is almost identical to [al6,rv] but I made a copy
just to be safe (no bugs, anyway). A duplicate copy
is on ROBOT4 for extra safety.
Remember that this is the one that Ron had changed some
of the constants in ALHDR for.
[AL8,RV] The first working version-2 Pascal AL, version 2.A.
Has full resident overlays and TKB-combined overlays.
No modules have been physically combined.
Has a few bugs but otherwise seems to work.